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Abstract 

Software architecture is receiving increasingly atten- 
tion as a critical design level for software systems. As 
software architecture design resources (in the form of ar- 
chitectural specifications) are going to be accumulated, 
the development of techniques and tools to support ar- 
chitectural understanding, testing, reengineering, main- 
tenance, and reuse will become an important issue. This 
paper introduces a new form of slicing, named archi- 
tectural slicing, to aid architectural understanding and 
reuse. In contrast to traditional slicing, architectural 
slicing is designed to operate on the architectural spec- 
ification of a software system, rather than the source 
code of a program. Architectural slicing provides knowl- 
edge about the high-level structure of a software system, 
rather than the low-level implementation details of a 
program. In order to compute an architectural slice, we 
present the architecture information flow graph which 
can be used to represent information flows in a software 
architecture. Based on the graph, we give a two-phase 
algorithm to compute an architectural slice. 

1 Introduction 

Software architecture is receiving increasingly atten- 
tion as a critical design level for software systems 
The software architecture of a system defines its high- 
level structure, exposing its gross organization as a col- 
lection of interacting components. A well-defined ar- 
chitecture allows an engineer to reason about system 
properties at a high level of abstraction. Architectural 
description languages (ADLs) are formal languages that 
can be used to represent the architecture of a software 
system. They focus on the high-level structure of the 
overall application rather than the implementation de- 
tails of any specific source module. Recently, a number 
of architectural description languages have been pro- 
posed such as Wright ||], Rapide Q, UniCon and 
ACME 1^ to support formal representation and reason- 
ing of software architectures. As software architecture 
design resources (in the form of architectural specifica- 
tions) are going to be accumulated, the development 
of techniques to support software architectural under- 
standing, testing, reengineering, maintenance and reuse 
will become an important issue. 

One way to support software architecture develop- 



ment is to use slicing technique. Program slicing, origi- 
nally introduced by Weiser |^ , is a decomposition tech- 
nique which extracts program elements related to a par- 
ticular computation. A program slice consists of those 
parts of a program that may directly or indirectly affect 
the values computed at some program point of interest, 
referred to as a slicing criterion. The task to compute 
program slices is called program slicing. To understand 
the basic idea of program slicing, consider a simple ex- 
ample in Figure l] which shows: (a) a program frag- 
ment and (b) its slice with respect to the slice criterion 
(Total, 14). The slice consists of only those statements 
in the program that might affect the value of variable 
Total at line 14. The lines represented by small rectan- 
gles are statements that have been sliced away. We refer 
to this kind of slicing as traditional slicing to distinguish 
it from a new form of slicing introduced later. 

Traditional slicing has been studied primarily in the 
context of conventional programming languages pl| . 
In such languages, slicing is typically performed by 
using a control fiow graph or a dependence graph 
§, PI @, |l6m, ||. Traditional slicing has many ap- 
plications in software engineering activities including 
program understandin g p] , debugging [Q, testing 
maintenance |^ , reuse |]15 | , r everse engineering |^ , and 
complexity measurement ||lq] . 

Applying slicing technique to software architectures 
promises benefit for software architecture development 
at least in two aspects. First, architectural understand- 
ing and maintenance should benefit from slicing. When 
a maintainer wants to modify a component in a software 
architecture in order to satisfy new design requirements, 
the maintainer must first investigate which components 
will affect the modified component and which compo- 
nents will be affected by the modified component. This 
process is usually called impact analysis. By slicing a 
software architecture, the maintainer can extract the 
parts of a software architecture containing those compo- 
nents that might affect, or be affected by, the modified 
component. The slicing tool which provides such infor- 
mation can assist the maintainer greatly. Second, archi- 
tectural reuse should benefit from slicing. While reuse 
of code is important, in order to make truly large gains 
in productivity and quality, reuse of software designs 
and patterns may offer the greater potential for return 
on investment. By slicing a software architecture, a sys- 



(a) A program fragment . 

1 begin 

2 read (X, Y) ; 

3 Total := 0.0; 

4 Sum := 0.0; 

5 if X <= 1 then 

6 Sum := Y; 

7 else 

8 begin 

9 read(Z); 

10 Total := X * Y; 

11 end; 

12 end if 

13 Write (Total, sum); 

14 end 



(b) a slice of (a) on the criterion (Total, 14). 

1 begin 

2 read(X,Y); 

3 Total := 0.0; 



5 if X <= 1 then 



7 else 

8 begin 



10 Total := X * Y; 

11 end; 

12 end if 



14 end 

Figure 1 : A program fragment and its slice on criterion 
(Total, 14). 



tern designer can extract reusable architectures from it, 
and reuse them into new system designs for which they 
are appropriate. 

While slicing is useful in software architecture devel- 
opment, existing slicing techniques for conventional pro- 
gramming languages can not be applied to architectural 
specifications straightforwardly due to the following rea- 
sons. Generally, the traditional definition of slicing is 
concerned with slicing programs written in conventional 
programming languages which primarily consist of vari- 
ables and statements, and the slicing notions are usually 
defined as (1) a slicing criterion is a pair (s, V) where 
s is a statement and F is a set of variables defined or 
used at s, and (2) a slice consists of only statements. 
However, in a software architecture, the basic elements 
are components and their interconnections, but neither 
variables nor statements as in conventional program- 
ming languages. Therefore, to perform slicing at the 
architectural level, new slicing notions for software ar- 
chitectures must be defined. 

In this paper, we introduce a new form of slicing, 
named architectural slicing. In contrast to traditional 



slicing, architectural slicing is designed to operate on 
a formal architectural specification of a software sys- 
tem, rather than the source code of a conventional pro- 
gram. Architectural slicing provides knowledge about 
the high-level structure of a software system, rather 
than the low-level implementation details of a conven- 
tional program. Our purpose for development of archi- 
tectural slicing is different from that for development 
of traditional slicing. While traditional slicing was de- 
signed originally for supporting source code level un- 
derstanding and debugging of conventional programs, 
architectural slicing was primarily designed for support- 
ing architectural level understanding and reuse of large- 
scale software systems. However, just as traditional slic- 
ing has many other applications in software engineering 
activities, we believe that architectural slicing is also 
useful in other software architecture development activ- 
ities including architectural testing, reverse engineering, 
reengineering, and complexity measurement. 

Abstractly, our slicing algorithm takes as input a for- 
mal architectural specification (written in its associated 
architectural description language) of a software system, 
then it removes from the specification those components 
and interconnections between components which are not 
necessary for ensuring that the semantics of the specifi- 
cation of the software architecture is maintained. This 
benefit allows unnecessary components and interconnec- 
tions between components to be removed at the archi- 
tectural level of the system which may lead to consid- 
erable space savings, especially for large-scale software 
systems whose architectures consist of numerous com- 
ponents. In order to compute an architectural slice, we 
present the architecture information flow graph which 
can be used to represent information flows in a software 
architecture. Based on the graph, we give a two-phase 
algorithm to compute an architectural slice. 

The rest of the paper is organized as follows. Section 
1^ briefly introduces how to represent a software archi- 
tecture using Wright: an architectural description lan- 
guage. Section |^ shows a motivation example. Section 
^ defines some notions about slicing software architec- 
tures. Section |^ presents the architecture information 
flow graph for software architectures . Section || gives 
a two-phase algorithm for computing an architectural 
slice. Section |^ discusses the related work. Concluding 
remarks are given in Section |^. 

2 Software Architectural Specification 
in Wright 

We assume that readers are familiar with the basic 
concepts of software architecture and architectural de- 
scription language, and in this paper, we use Wright 
architectural description language [|| as our target lan- 
guage for formally representing software architectures. 
The selection of Wright is based on that it supports to 
represent not only the architectural structure but also 
the architectural behavior of a software architecture. 

Below, we use a simple Wright architectural speci- 



Configuration GasStation 
Component Customer 

Port Pay = pay!x — > Pay 

Port Gas = take pump?x ^ Gas 

Computation = Pay.paylx — > Gas. take — ► Gas.pump?x — ► Computation 
Component Cashier 

Port Customerl = pay?x — > Customerl 
Port Customer2 = pay?x — > Customer2 
Port Topump = pumplx — > Topump 

Computation = Customerl. pay ?x — > Topump. pumplx — > Computation 
[] Customer2.pay?x — ► Topump. pumplx — > Computation 
Component Pump 

Port Gill = take — > pumplx Gill 

Port Oil2 = take pumplx Gil2 

Port Fromcashier = pumpYx — > Fromcashier 

Computation = Fromcashier. pump?x — > 

(Gill. take — > Gill. pumplx — > Computation) 
[] (Gil2.take — > Gil2. pumplx — > Computation) 
Connector Customer .Cashier 

Role Givemoney = paylx — > Givemoney 

Role Getmoney = pay?x —> Getmoney 

Glue = Givemoney.pay?x — > Getmoney.paylx — > Glue 
Connector Customer_Pump 

Role Getoil = take pump?x Getoil 

Role Giveoil = take — > pumplx Giveoil 

Glue = Getoil. take — > Giveoil. take — > Giveoil. pump?x Getoil. pumplx — + Glue 
Connector Cashier_Pump 

Role Tell = pumplx Tell 

Role Know = pump?x — > Know 

Glue = Tell.pump?x — > Know. pumplx —> Glue 
Instances 

Customerl: Customer 

Customer2: Customer 

cashier: Cashier 

pump: Pump 

Customer l_cashier: Customer .Cashier 
Customer2_cashier: Customer .Cashier 
Customerl_pump: Customer_Pump 
Customer2_pump: Customer_Pump 
cashier_pump: Cashier_Pump 
Attachments 

Customerl. Pay as Customerl_cashier. Givemoney 
Customerl. Gas as Customerl_pump. Getoil 
Customer2.Pay as Customer2_cashier. Givemoney 
Customer2.Gas as Customer2_pump. Getoil 
easier. Customerl as Customerl_cashier. Getmoney 
easier. Customer2 as Customer2_cashier. Getmoney 
cashier. Topump as cashier_pump.Tell 
pump. Fromcashier as cashier_pump.Know 
pump. Gill as Customerl_pump. Giveoil 
pump.Gil2 as Customer2_pump. Giveoil 
End GasStation. 



Figure 2: An architectural specification in Wright. 



fication taken from as a sample to briefly introduce 
how to use Wright to represent a software architecture. 
The specification is showed in Figure ^ which models the 
system architecture of a Gas Station system . 

2.1 Representing Architectural Structure 

Wright uses a configuration to describe architec- 
tural structure as graph of components and connectors. 

Components are computation units in the system. In 
Wright, each component has an interface defined by a 
set of ports. Each port identifies a point of interaction 
between the component and its environment. 

Connectors are patterns of interaction between com- 
ponents. In Wright, each connector has an interface 
defined by a set of roles. Each role defines a participant 
of the interaction represented by the connector. 



A Wright architectural specification of a system is 
defined by a set of component and connector type defini- 
tions, a set of instantiations of specific objects of these 
types, and a set of attachments. Attachments specify 
which components are linked to which connectors. 

For example, in Figure ^ there are three compo- 
nent type definitions, Customer, Cashier and Pump, and 
three connector type definitions, Customer_Cashier, 
Customer_Pump and Cashier_Pump. The configuration 
is composed of a set of instances and a set of attach- 
ments to specify the architectural structure of the sys- 
tem. 

2.2 Representing Architectural Behavior 

Wright models architectural behavior according to 
the significant events that take place in the computa- 



Customerl 




pump 



Customer2 



Figure 3: The architecture of the Gas Station system. 



tion of components, and the interactions between com- 
ponents as described by the connectors. The nota- 
tion for specifying event-based behavior is adapted from 
CSP (lO). Each CSP process defines an alphabet of 
events and the permitted patterns of events that the 
process may exhibit. These processes synchronize on 
common events (i.e., interact) when composed in paral- 
lel Wright uses such process descriptions to describe 
the behavior of ports, roles, computations and glues. 

A computation specification specifies a component's 
behavior: the way in which it accepts certain events on 
certain ports and produces new events on those or other 
ports. Moreover, Wright uses an overbar to distin- 
guish initiated events from observed events Q For ex- 
ample, the Customer initiates Pay action (i.e., pay!x) 
while the Cashier observes it (i.e., pay?x). 

A port specification specifies the local protocol with 
which the component interacts with its environment 
through that port. 

A role specification specifies the protocol that must 
be satisfied by any port that is attached to that role. 
Generally, a port need no have the same behavior as the 
role that it fills, but may choose to use only a subset of 
the connector capabilities. For example, the Customer 
role Gas and the Customer _Pump port Get oil are iden- 
tical. 

A glue specification specifies how the roles of a 
connector interact with each other. For example, a 
Cashier_Pump tell (Tell.pump?x) must be transmitted 
to the Cashier_Pump know (Know . pump ! x) . 

As a result, based on formal Wright architectural 
specifications, we can infer which ports of a component 
are input ports and which are output ports. Also, we 
can infer which roles are input roles and which are out- 

*In this paper, we use an underbar to represent an ini- 
tiated event instead of an overbar that used in the original 
Wright language definition Q. 



put roles. Moreover, the direction in which the infor- 
mation transfers between ports and/or roles can also 
be inferred based on the formal specification. As we 
will show in Section ^ such kinds of information can be 
used to construct the information flow graph for a soft- 
ware architecture for computing an architectural slice 
efiiciently. 

In order to focus on the key ideas of architectural 
slicing, in this paper we assume that a software archi- 
tecture be represented by a formal architectural speci- 
fication which contains three basic types of design en- 
tities, namely, components whose interfaces are defined 
by a set of elements called ports, connectors whose in- 
terfaces are defined by a set of elements called roles and 
the configuration whose topology is declared by a set of 
elements called instances and attachments. Moreover, 
each component has a special element called computa- 
tion and each connector has a special element called glue 
as we described above. 

In the rest of the paper, we assume that an architec- 
tural specification P be denoted by {Cm, Cn, Cg) where: 

• Cm is the set of components in P, 

• Cn is the set of connectors in P, and 

• Cg is the configuration of P. 

3 Motivation Example 

We present a simple example to explain our approach 
on architectural slicing. The example also shows one 
application of architectural slicing, in which it is used 
in the impact analysis of software architectures. 

Consider the Gas Station system whose architectural 
representation is shown in Figure |3[ and Wright spec- 
ification is shown in Figure ^. Suppose a maintainer 
needs to modify the component cashier in the archi- 
tectural specification in order to satisfy some new de- 
sign requirements. The first thing the maintainer has 
to do is to investigate which components and connec- 
tors interact with component cashier through its ports 
Customer 1, Customer2, and Topump. A common way 
is to manually check the source code of the specifica- 
tion to find such information. However, it is very time- 
consuming and error-prone even for a small size speci- 
fication because there may be complex dependence re- 
lations between components in the specification. If the 
maintainer has an architectural sheer at hand, the work 
may probably be simplified and automated without the 
disadvantages mentioned above. In such a scenario, 
an architectural sheer is invoked, which takes as input: 
(1) a complete architectural specification of the system, 
and (2) a set of ports of the component cashier, i.e.. 
Customer 1, Customer2 and Topump (this is an archi- 
tectural slicing criterion). The sheer then computes a 
backward and forward architectural slice respectively 
with respect to the criterion and outputs them to the 
maintainer. A backward architectural slice is a partial 



specification of the original one which includes those 
components and connectors that might affect the com- 
ponent cashier through the ports in the criterion, and 
a forward architectural slice is a partial specification of 
the original one which includes those components and 
connectors that might be affected by the component 
cashier through the ports in the criterion. The other 
parts of the specification that might not affect or be af- 
fected by the component cashier will be removed, i.e., 
sliced away from the original specification. The main- 
tainer can thus examine only the contents included in 
a slice to investigate the impact of modification. Us- 
ing the algorithm we will present in Section ^, the slice 
shown in Figure ^ can be computed. 

4 Architectural Slicing 

Intuitively, an architectural slice may be viewed as a 
subset of the behavior of a software architecture, simi- 
lar to the original notion of the traditional static slice. 
However, while a traditional slice intends to isolate the 
behavior of a specified set of program variables, an ar- 
chitectural slice intends to isolate the behavior of a spec- 
ified set of a component or connector's elements. Given 
an architectural specification P = (Cm, Cn, Cg), our goal 
is to compute an architectural slice Sp = {C'^,C'^,c'g) 
which should be a "sub-architecture" of P and preserve 
partially the semantics of P. To define the meanings of 
the word "sub-architecture," we introduce the concepts 
of a reduced component, connector and configuration. 

Definition 4.1 Let P = {Cm,Cn,Cg) be an architec- 
tural specification and Cm G Cm; c„ e C„, and Cg be 
a component, connector, and configuration of P respec- 
tively: 

• A reduced component o/c„i is a component c'.^ that 
is derived from Cm by removing zero, or more ele- 
ments from Cm ■ 

• A reduced connector of Cn is a connector c'^ that is 
derived from c„ by removing zero, or more elements 
from Cn- 

• A reduced configuration of Cg is a configuration c'g 
that is derived from Cg by removing zero, or more 
elements from Cg . 

The above definition showed that a reduced compo- 
nent, connector, or configuration of a component, con- 
nector, or configuration may equal itself in the case that 
none of its elements has been removed, or an empty com- 
ponent, connector, or configuration in the case that all 
its elements have been removed. 

For example, the foUowings show a component 
Customer, a connector Customer_Cashier, and a con- 
figuration as well as their corresponding reduced com- 
ponent, connector, and configuration. The small rect- 
angles represent those ports, roles, or instances and at- 
tachments that have been removed from the original 



component, connector, or configuration. 

(1) The component Customer and its reduced compo- 
nent (with * mark) in which the port Gas and elements 
Gas ■ take and Gas . pump?x that are related to Gas in 
the computation have been removed. 

Component Customer 

Port Pay = pay!x Pay 

Port Gas = take pump?x Gas 

Computation = Pay.paylx Gas. take 

— > Gas.pump?x Computation 

* Component Customer 

Port Pay = pay!x Pay 

□□□□□□□□□□□□□□□□□□□□ 
Computation = Pay.paylx □□□□□□ 

□□□□□□ Computation 

(2) The connector Customer_Cashier and its re- 
duced connector (with * mark) in which the role 
Givemoney and the element Givemoney .pay?x that is 
related to Givemoney in the glue have been removed. 

Connector Customer_Cashier 

Role Givemoney = pay!x Givemoney 
Role Getmoney = pay?x — > Getmoney 
Glue = Givemoney.pay?x Getmoney.paylx 
^ Glue 

* Connector Customer_Cashier 

□□□□□□□□□□□□□□□□□□□□ 
Role Getmoney = pay?x Getmoney 
Glue = □□□□□□□□□□ Getmoney.paylx 
^ Glue 

(3) The configuration and its reduced configuration 
(with * mark) in which some instances and attachments 
have been removed. 

Instances 

Customer 1: Customer 
Customer2: Customer 
cashier: Cashier 
pump: Pump 

Customer 1 .cashier : Customer .Cashier 
Customer2_cashier: Customer .Cashier 
Customerl_pump: Customer_Pump 
Customer2_pump: Customer _Pump 
cashier _pump: Cashier _Pump 
Attachments 

Customerl.Pay as Customerl_cashier. Givemoney 
Customerl.Gas as Customerl_pump.Getoil 
Customer2.Pay as Customer2_cashier. Givemoney 
Customer2.Gas as Customer2_pump.Getoil 
easier. Customerl as Customerl_cashier. Getmoney 
easier. Customer2 as Customer2_cashier. Getmoney 
cashier. Topump as cashier _pump. Tell 
pump.Fromcashier as cashier_pump.Know 
pump. Gill as Customerl_pump.Giveoil 
pump.Oil2 as Customer2_pump.Giveoil 



* Instances 

Customer 1: Customer 
Customer2: Customer 
cashier: Cashier 

□□□□□□□□ 

Customer 1 .cashier: Customer .Cashier 
Customer2_cashier: Customer .Cashier 

□□□□□□□□□□□□□□□□□□□□□ 
□□□□□□□□□□□□□□□□□□□□□ 
□□□□□□□□□□□□□□□□□□ 

* Attachments 

Customerl.Pay as Customerl_cashier.Givemoney 

□□□□□□□□□□□□□□□□□□□□□□□□□□□ 

Customer2.Pay as Customer2_cashier.Givemoney 

□□□□□□□□□□□□□□□□□□□□□□□□□□□ 

easier. Customerl as Customerl_cashier.Getmoney 

easier. Customer2 as Customer2_cashier.Getmoney 

□□□□□□□□□□□□□□□□□□□□□□□□ 

□□□□□□□□□□□□□□□□□□□□□□□□□□□ 

□□□□□□□□□□□□□□□□□□□□□□□□ 

□□□□□□□□□□□□□□□□□□□□□□□□ 



Having the definitions of a reduced component, con- 
nector and configuration, we can define the meaning of 
the word "sub-architecture" . 



Definition 4.2 Let P 



{Cm,Cn,Cg) and P' 



{C'j„,C!^,c'g) be two architectural specifications. Then 
P' is a reduced architectural specification of P if: 



C =^ (r' r' 



, c'„ } is a "subset" of Cm ~ 



■ jCmfc} such that for i — 1,2,, 



c^j . is a reduced component of c„ 
C'n = Wm,c'„2'---'^'nJ « "subset" of Cn 



, , c„^ } such that for i = 1,2, . . . ,k, c'^. 



is a reduced connector of c„; , 



c'g is a reduced configuration of c, 



v 



Having the definition of a reduced architectural spec- 
ification, we can define some notions about slicing soft- 
ware architectures. 

In a Wright architectural specification, for exam- 
ple, a component's interface is defined to be a set of 
ports which identify the form of the component inter- 
acting with its environment, and a connector's interface 
is defined to be a set of roles which identify the form of 
the connector interacting with its environment. To un- 
derstand how a component interacts with other compo- 
nents and connectors for making changes, a maintainer 
must examine each port of the component of interest. 
Moreover, it has been frequently emphasized that con- 
nectors are as important as components for architec- 
tural design, and a maintainer may also want to modify 
a connector during the maintenance. To satisfy these 
requirements, for example, we can define a slicing cri- 
terion for a Wright architectural specification as a set 
of ports of a component or a set of roles of a connector 
of interest. 

Definition 4.3 Let P = {Cm,Cn,Cg) be an architec- 
tural specification. A slicing criterion for P is a pair 
(c, E) such that: 



L c E C'm cind E is a set of elements of c, or 
2. c G C'n and E is a set of elements of c. 

Note that the selection of a slicing criterion depends 
on users' interests on what they want to examine. If 
they are interested in examining a component in an ar- 
chitectural specification, they may use slicing criterion 
1. If they are interested in examining a connector, they 
may use slicing criterion 2. Moreover, the determina- 
tion of the set E also depends on users' interests on 
what they want to examine. If they want to examine 
a component, then E may be the set of ports or just a 
subset of ports of the component. If they want to ex- 
amine a connector, then E may be the set of roles or 
just a subset of roles of the connector. 



Definition 4.4 Let P 

tural specification. 



{C.m,Cn,Cg) be an architec- 



• A backward architectural shce Sbp = {C'm,C^,Cg) 
of P on a given slicing criterion (c, E) is a reduced 
architectural specification of P which contains only 
those reduced components, connectors, and config- 
uration that might directly or indirectly affect the 
behavior of c through elements in E. 

• Backward-slicing an architectural specification P 
on a given slicing criterion is to find the backward 
architectural slice of P with respect to the criterion. 



Definition 4.5 Let P — (Cm,C„,Cg) be an architec- 
tural specification. 

• A forward architectural shce Sfp = {C'm,C^,Cg) 
of P on a given slicing criterion (c, E) is a reduced 
architectural specification of P which contains only 
those reduced components, connectors, and config- 
uration that might be directly or indirectly affected 
by the behavior of c through elements in E. 

• Forward-slicing an architectural specification P on 
a given slicing criterion is to find the forward ar- 
chitectural slice of P with respect to the criterion. 



From Definitions 
there is at least one 



4.4 and 4.5, it is obviously that 
backward slice and at least one 



forward slice of an architectural specification that is the 
specification itself. Moreover, the architecture repre- 
sented by Sbp or Sfp should be a "sub-architecture" of 
the architecture represented by P. 

Defining an architectural slice as a reduced architec- 
tural specification of the original one is particularly use- 
ful for supporting architectural reuse. By using an ar- 
chitectural sheer, a system designer can automatically 
decompose an existing architecture (in the case that its 
architectural specification is available) into some small 
architectures each having its own functionality which 
may be reused in new system designs. Moreover, the 
view of an architectural slice as a reduced architectural 
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Figure 4: The information flow graph of the architectural specification in Figure ^ 



specification dose not reduce its usefulness when applied 
it to architectural understanding because it also con- 
tains enough information for a maintainer to facilitate 
the modification. 



5 The Information Flow Graph for Soft- 
ware Architectures 

In this section, we present the architecture informa- 
tion flow graph for software architectures on which ar- 
chitectural slices can be computed efficiently. 

The architecture information flow graph is an arc- 
classified digraph whose vertices represent the ports of 
components and the roles of the connectors in an archi- 
tectural specification, and arcs represent possible infor- 
mation flows between components and/or connectors in 
the specification. 

Definition 5.1 The Architecture Information Flow 
Graph (AIFG) of an architectural specification P is 
an arc- classified digraph (Vcom,VcomCom,Con, Int), 
where: 

• Vcom is the set of port vertices of P; 

• Vcori is th^ set of role vertices of P; 

• Com is the set of component- connector flow arcs; 

• Con is the set of connector- component flow arcs; 

• Int is the set of internal flow arcs. 



There are three types of information flow arcs in 
the AIFG, namely, component- connector flow arcs, 
connector- component flow arcs, and internal flow arcs. 

Component-connector flow arcs are used to represent 
information flows between a port of a component and 
a role of a connector in an architectural specification. 
Informally, if there is an information flow from a port 
of a component to a role of a connector in the specifl- 
cation, then there is a component-connector flow arc in 
the AIFG which connects the corresponding port vertex 
to the corresponding role vertex. For example, from the 
Wright specification shown in Figure ^ we can know 
that there is an information flow from the port Topump 
of the component cashier to the role Tell of the con- 
nector cashier_pump. Therefore there is a component- 
connector flow arc in the AIFG in Figure ^ which con- 
nects the port vertex of port Topump to the role vertex 
of role Tell. 

Connector-component flow arcs are used to represent 
information flows between a role of a connector and a 
port of a component in an architectural specification. 
Informally, if there is an information flow from a role 
of a connector to a port of a component in the speci- 
fication, then there is a connector-component flow arc 
in the AIFG which connects the corresponding role ver- 
tex to the corresponding port vertex. For example, from 
the Wright specification in Figure |[ we can know that 
there is an information flow from the role Know of the 
connector cashier_pump to the port Fromcashier of 
the component pump. Therefore, there is a connector- 
component flow arc in the AIFG in Figure ^ which con- 
nects the role vertex for role Know to the port vertex for 
port Fromcashier. 



Internal flow arcs are used to represent internal in- 
formation flows within a component or connector in an 
architectural specification. Informally, for a component 
in the specification, there is an internal flow fi'om an 
input port to an output port, and for a connector in 
the specification, there is an internal flow fi'om an in- 
put role to an output role. For example, in Figure ^ 
there is an internal flow from the role Givemoney to 
the role Getmoney of the connector Customerl_cashier 
and also an internal flow arc from the port Fromcashier 
to the port Dill of component pump. 

As we introduced in Section |[ Wright uses CSP- 
based model to specify the behavior of a component and 
a connector of a software architecture. Wright allows 
user to infer which ports of a component are input and 
which are output, and which roles of a connector are 
input and which are output based on a Wright archi- 
tectural specification. Moreover, it also allows user to 
infer the direction in which the information transfers be- 
tween ports and/or roles. As a result, by using a static 
analysis tool which takes an architectural specification 
as its input, we can construct the AIFG of a Wright 
architectural specification automatically. 

Figure ^ shows the AIFG of the architectural specifi- 
cation in Figure I In the fi gure, large squares represent 
components in the specification, and small squares rep- 
resent the ports of each component. Each port vertex 
has a name described by component_name.port_name. 
For example, pv5 (cashier . Customerl) is a port ver- 
tex that represents the port Customerl of the compo- 
nent cashier. Large circles represent connectors in 
the specification, and small circles represent the roles 
of each connector. Each role vertex has a name de- 
scribed by connector_name. role-name. For example, rv5 
(cashier_pump . Tell) is a role vertex that represents 
the role Tell of the connector cashier_pump. The com- 
plete specification of each vertex is shown on the right 
side of the figure. 

Solid arcs represent component-connector fiow arcs 
that connect a port of a component to a role of a connec- 
tor. Dashed arcs represent connector-component flow 
arcs that connect a role of a connector to a port of 
a component. Dotted arcs represent internal flow arcs 
that connect two ports within a component (from an 
input port to an output port), or two roles within a con- 
nector (from an input role to an output role) . For exam- 
ple, {rv2,pv5) and {rv6,pv8) sue connector-component 
flow arcs. {pv7, rv5) and {pv9, rv8) are component- 
connector flow arcs. {rvl,rv2) and (pu8,pul0) are in- 
ternal flow arcs. 

6 Computing Architectural Slices 

The slicing notions defined in Section ^ give us only 
a general view of an architectural slice, and do not tell 
us how to compute it. In this section we present a two- 
phase algorithm to compute a slice of an architectural 
specification based on its information flow graph. Our 
algorithm contains two phases: (1) Computing a slice 



Sg over the information flow graph of an architectural 
specification, and (2) Constructing an architectural slice 
Sp from Sg. 

6.1 Computing a Slice over the AIFG 

Let P — {Cm,Cn,Cg) be an architectural specifica- 
tion and G = {Vcom, Vcon, Com, Con, Int) be the AIFG 
of P. To compute a slice over the G, we refine the slicing 
notions defined in Section ^ as follows: 

• A slicing criterion for G is a pair (c, Vc) such that: 
(1) c G Cm CLrid Vc is a set of port vertices corre- 
sponding to the ports of c, or (2) c ^ Cn and Vc is 
a set of role vertices corresponding to roles of c. 

• The backward slice Sbg{c, Vc) of C on a given slic- 
ing criterion (c, Vc) is a subset of vertices of G such 
that for any vertex v of G, v ^ Sbg{c, Vc) iff there 
exists a path from v to v' d Vc in the AIFG. 

• The forward slice Sfg{c, Vc) of G on a given slicing 
criterion (c, Vc) is a subset of vertices of G such 
that for any vertex v of G, v G Sfg{c, Vc) iff there 
exists a path from v' G Vc to v in the AIFG. 

According to the above descriptions, the computa- 
tion of a backward slice or forward slice over the AIFG 
can be solved by using an usual depth-first or breath- 
first graph traversal algorithm to traverse the graph by 
taking some port or role vertices of interest as the start 
point of interest. 

Figure || shows a backward slice over the AIFG with 
respect to the slicing criterion (cashier, Vc) such that 
Vc = {pv5,pv6,pv7}. 

6.2 Computing an Architectural Slice 

The slice Sg computed above is only a slice over the 
AIFG of an architectural specification, which is a set 
of vertices of the AIFG. Therefore we should map each 
element in Sg to the source code of the specification. Let 
P — (Cm,C„,Cg) be an architectural specification and 
G = {Vcom, Vcon, Com, Con, Int) be the AIFG of P. By 
using the concepts of a reduced component, connector, 
and configuration introduced in Section ^, a slice Sp = 
{C'm,C'i^,c'g) of an architectural specification P can be 
constructed in the following steps: 

1. Constructing a reduced component from a com- 
ponent Cm by removing all ports such that their 
corresponding port vertices in G have not been in- 
cluded in Sg and unnecessary elements in the com- 
putation from Cm- The reduced components C'm in 
Sp have the same relative order as the components 
Cm in P- 

2. Constructing a reduced connector c'„ from a con- 
nector Cn by removing all roles such that their cor- 
responding role vertices in G have not been in- 
cluded in Sg and unnecessary elements in the glue 
from c„ . The reduced connectors C' in Sr, have the 
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Figure 5: A slice over the AIFG of the architectural specification in Figure 



same relative order as their corresponding connec- 
tors in P. 

3. Constructing the reduced configuration from the 
configuration Cg by the following steps: 

— Removing all component and connector in- 
stances from Cg that are not included in C'^ 
and C^. 

— Removing all attachments from Cg such that 
there exists no two vertices vi and V2 where 
Vi,V2 S Sg and vl as v2 represents an at- 
tachment. 

— The instances and attachments in the reduced 
configuration in Sp have the same relative or- 
der as their corresponding instances and at- 
tachments in P. 

Figure ^ shows a backward slice of the Wright spec- 
ification in Figure ^ with respect to the slicing criterion 
(cashier, E) such that E={Customerl, Customer2, 
Topump} is a set of ports of component cashier. The 
small rectangles represent the parts of specification that 
have been removed, i.e., sliced away from the original 
specification. The slice is obtained from a slice over 
the AIFG in Figure |5| according to the mapping pro- 
cess described above. Figure ^ shows the architectural 
representation of the slice in Figure ^. 

7 Related Work 

7.1 Software Architecture Dependence 
Analysis 

Perhaps, the most similar work with ours is that pre- 
sented by Stafford, Richardson and Wolf who intro- 
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Figure 7: The architectural representation of the slice 
in Figure |^. 



duced a software architecture dependence analysis tech- 
nique, called chaining to support software architecture 
development such as debugging and testing. In chain- 
ing, links represent the dependence relationships that 
exist in an architectural specification. Links connect 
elements of the specification that are directly related, 
producing a chain of dependences similar to a slice in 
traditional slicing that can be followed during analysis. 
Although their consideration is similar to ours, there 
are still some differences between their work and ours. 
First, the slicing criterions are different. While Stafford, 
Richardson, and Wolf define a slicing criterion of an ar- 
chitectural specification as a set of ports of a component. 



Configuration GasStation 
Component Customer 

Port Pay = pay!x — > Pay 
□□□□□□□□□□□□□□□□□□□□□□ 

Computation = Pay.paylx — + Gas. take — > Gas.pump?x — > Computation 
Component Cashier 

Port Customerl = pay?x — > Customerl 
Port Customer2 = pay?x Customer2 
Port Topump = pumplx Topump 

Computation = Customerl. pay?x — > Topump. pumplx — > Computation 
[] Customer2.pay?x Topump. pumplx — > Computation 

□□□□□□□□□□□□□□□□□ 

□□□□□□□□□□□□□□□□□□□□□□ 

□□□□□□□□□□□□□□□□□□□□□□ 

□□□□□□□□□□□□□□□□□□□□□□□□□□ 

□□□□□□□□□□□□□□□□□□□□□□□□□□□ 

□□□□□□□□□□□□□□□□□□□□□□□□□□□ 
□□□□□□□□□□□□□□□□□□□□□□□□□□□ 
Connector Customer_Cashier 

Role Givemoney = paylx — » Givemoney 

Role Getmoney = payYx — > Getmoney 

Glue = Givemoney. pay ?x Getmoney.paylx Glue 
□□□□□□□□□□□□□□□□□ 

□□□□□□□□□□□□□□□□□□□□□□□□□□ 

□□□□□□□□□□□□□□□□□□□□□□□□□□ 

□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□ 
□□□□□□□□□□□□□□□□□ 

□□□□□□□□□□□□□□□□□□□□□ 

□□□□□□□□□□□□□□□□□□□□□ 

□□□□□□□□□□□□□□□□□□□□□□□□□□□ 
Instances 

Customerl: Customer 

Customer2: Customer 

cashier: Cashier 

□□□□□□□□ 

Customerl_cashier: Customer .Cashier 

Customer2_cashier : Customer .Cashier 

□□□□□□□□□□□□□□□□□□□□□ 

□□□□□□□□□□□□□□□□□□□□□ 

□□□□□□□□□□□□□□□□□□ 
Attachments 

Customerl. Pay as Customerl_cashicr. Givemoney 

□□□□□□□□□□□□□□□□□□□□□□□□□□□ 

Customer2.Pay as Customer2_cashicr. Givemoney 

□□□□□□□□□□□□□□□□□□□□□□□□□□□ 

easier. Customerl as Customerl_cashier. Getmoney 

easier. Customer2 as Customer2_cashier. Getmoney 

□□□□□□□□□□□□□□□□□□□□□□□□ 

□□□□□□□□□□□□□□□□□□□□□□□□□□□ 

□□□□□□□□□□□□□□□□□□□□□□□□ 

□□□□□□□□□□□□□□□□□□□□□□□□ 
End GasStation. 



Figure 6: A backward slice of the architectural specification in Figure 



we defined a slicing criterion as either a set of ports of 
a component or a set of roles of a connector of an archi- 
tectural specification. This is because that in addition 
to modifying a component, in some cases, a maintainer 
may also want to modify a connector. Second, the types 
of architectural slices are different. Stafford, Richard- 
son, and Wolf compute an architectural slice that in- 
cludes only a set of components of an architectural spec- 
ification, and therefore, it seems that their slices fail 
to capture the information concerning interactions be- 
tween these components. In contrast, we compute an 
architectural slice that includes not only a set of com- 
ponents but also connectors (interactions between these 
components). Moreover, since our architectural slice is 
a reduced architectural specification of the original one 
and can also preserve the partial semantics of the orig- 
inal architectural specification, our slice is particularly 



useful in software architecture reuse. 
7.2 Class Slicing for C++ 

Tip et. al p2| introduced an algorithm for slicing class 
hierarchies in C++ programs. Given a C++ class hier- 
archy (a collection of C++ class and inheritance rela- 
tions among them) and a program that uses the hierar- 
chy, the algorithm eliminates from the hierarchy those 
data members, member of functions, classes, and inher- 
itance relations that are unnecessary for ensuring that 
the semantics of the program is maintained. The class 
slicing has the benefit of allowing unused components of 
classes to be eliminated in applications that do not use 
those components. In this aspect, our work is strongly 
inspired by their work in the sense that we also want to 
use architectural slicing to remove unused components 
at the architectural level of software systems to narrow 



the domain on which reasoning about bugs is performed 
during the debugging at the architectural leveL 

7.3 Generalized Slicing 

Another work beyond traditional slicing is presented 
by Sloane and Holdsworth . They observed that two 
assumptions implicit in the definition of a traditional 
slice for programs written in imperative programming 
languages: (1) that variables and statements are con- 
cepts of the programming language in which program is 
written, and (2) that slices consist only of statements. 
For a language that does not have variables and state- 
ments, for example, a compiler specification language, 
traditional slicing does not make sense. To solve this 
problem, they introduced the generalized slicing as an 
extension of the traditional slicing by replacing variables 
with arbitrary named program entities and statements 
with arbitrary program constructs. This allows them 
to perform the slicing of non-imperative programs. Our 
work has a similar goal with theirs, but focuses specially 
on software architectures. 

8 Concluding Remarks 

We introduced a new form of slicing, named archi- 
tectural slicing to aid architectural understanding and 
reuse. In contrast to the traditional slicing, architec- 
tural slicing is designed to operate on the architec- 
tural specification of a software system, rather than the 
source code of a program. Architectural slicing provides 
knowledge about the high-level structure of a software 
system, rather than the low-level implementation details 
of a program. In order to compute an architectural slice, 
we presented the architecture information flow graph to 
explicitly represent information flows in a formal archi- 
tectural specification. Based on the graph, we gave a 
two-phase algorithm to compute an architectural slice. 

While our initial exploration used Wright as 
the architecture description language, the concept 
and approach of architectural slicing are language- 
independent. However, the implementation of an ar- 
chitectural slicing tool may differ from one architecture 
description language to another because each language 
has its own structure and syntax which must be handled 
carefully. 

In architectural description languages, in addition to 
provide both a conceptual framework and a concrete 
syntax for characterizing software architectures, they 
also provide tools for parsing, displaying, compiling, an- 
alyzing, or simulating architectural specifications writ- 
ten in their associated language. However, existing lan- 
guage environments provide no tools to support archi- 
tectural understanding, maintenance, testing, and reuse 
from an engineering viewpoint. We believe that some 
static analysis tools such as an architectural slicing tool 
introduced in this paper and an architectural depen- 
dence analysis tool [|l9[ should be provided by any 
ADL as an essential means to support these develop- 
ment activities. 



As future work, we would like to extend our approach 
presented here to handle other constructs in Wright 
language such as styles which were not considered here, 
and also to extend our approach to handle the slic- 
ing problem for other architecture description languages 
such as Rapide, ACME, and UniCon. To demonstrate 
the usefulness of our slicing approach, we are imple- 
menting a sheer for Wright architectural descriptions 
to support architectural level understanding and reuse. 
The next step for us is to perform some experiments to 
evaluate the usefulness of architectural slicing in prac- 
tical development of software architectures. 
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